In the transmission of data such as audio or video data, it is known to arrange the data into packet streams.
This means that firstly, the data is divided into discrete packets of a predetermined format, each packet comprising a header and a payload. The header may contain various types of control data including at least a packet identifier. The payload then contains the actual information content, i.e. the information such as the audio or video data that the end-user wishes to consume, sometimes also referred to as “user data”. The payload may be encoded for compression purposes and encrypted for security, such that the user data is typically not transmitted in its “raw” form. The packet may also comprise redundant information in the form of error correction codes for use in error correction at the receive side.
Secondly, the fact that the packets are part of a stream means that they have a certain sequential order and real-time requirement relating to their information content. Although a stream may be stored for later consumption, and/or its order or timing requirements need not necessarily be maintained during processing prior to consumption, when the stream is ultimately output to the user for consumption then the order and real-time requirements must be respected (at least on a practical level to a degree that is unnoticeable or tolerable to the user).
One technique for transmitting streams is to multiplex a plurality of streams into a combined stream known as a “transport stream”. An example application of this technique is shown schematically in FIG. 1, which shows a digital television transmitter 100 broadcasting digital media to a plurality of receiving user terminals 102. The transmitter 100 could for example be a satellite transmitter for transmitting wireless, digital transport stream signals via a network of one or more satellites; or a terrestrial television transmitter for transmitting wireless, digital transport stream signals via a network of one or more land-based repeater stations. A user terminal 102 could for example be a television set with and integrated digital receiver, a set-top box connected to a television set, a digital radio, or a portable terminal equipped with an appropriate receiver.
The transmitter 100 is to broadcast the content of a plurality of different concurrent television channels. In the terminology of transport streaming, a group of related streams intended for simultaneous consumption by the same user are together referred to as a program. For example, the output content of a television channel n may comprise a program in the form of a video stream, one or more audio streams (e.g. two in the case of stereo), and another data stream comprising other related data such as text summarising the program or data for use in an interactive service. In the terminology of transport streaming, each of these streams individually may be referred to as an “elementary stream”, which in packetised form comprises a plurality of “elementary packets”. That is, an elementary stream is a non-multiplexed stream of a single media type and single program.
The transmitter 100 may also broadcast the content of a radio station (i.e. pure audio content without video). For example, the output content of a radio station m may comprises a radio program in the form of one or more audio streams and another data stream providing program information.
The transmitter 100 may also transmit a separate data stream of other non-audio/video data not specifically related to any one particular channel or station, such as text providing program listings, or general interactive content.
At the transmitter 100, the audio, video and/or other data streams of each program are multiplexed together into a respective transport stream. Those transport streams are then multiplexed together into a combined transport stream for transmission. There is not necessarily a one-to-one relation between the elementary packets and the packets of the transport streams; i.e. the elementary streams may be repackaged, typically from longer, variable length elementary packets into shorter, fixed length transport packets. The multiplexing is then typically by time-division multiplexing such that transport packets are interleaved with one another in time.
To aid in selecting and handling the streams of the required program at the receivers 102, some control information is included in the transport stream by the transmitter 100. The transport packets of a program each comprise synchronisation information, typically in the form of a synchronisation byte. For example, the synchronisation bytes of a television program inform the receiver 102 how the audio streams are aligned in time with one another and with the corresponding video stream of that same program, allowing the audio and corresponding video to be synchronised at the receiver 102. Each transport packet also includes a Packet ID (PID) to identify the elementary stream from which it was derived. The transport stream then includes a Program Map Table (PMT) which maps together the PIDs of corresponding audio, video and data streams to their respective programs, i.e. identifies which streams are part of which programs.
Some receivers 102 may be arranged to receive multiple transport streams. For example, in addition to being able to receive a transport stream broadcast from the transmitter 100, a receiver 102 may also be able to retrieve stored transport streams from a hard drive 106, or transport streams via a wired connection to another source 108 such as a cable television provider or the Internet.
In addition to the above, it is also necessary to perform security operations as part of the transmit and receive processing of the transport streams. For example, this may involve encrypting the streams prior to transmission and decrypting them again at the receiver, so as to prevent unauthorised users exploiting the transmission.
Security operations can be implemented in dedicated hardware at the receiver 102. However, this has the disadvantage of being inflexible, since the security cannot be altered or updated without an expensive and time-consuming redesign and remanufacture of the receiver. Alternatively, the security operations can be implemented in software executed on the receiver's processor (typically in the form of firmware). However, although this software option allows more flexibility, it also has its own disadvantages over the hardware option. Firstly, the software security processing incurs additional machine cycles and thus may interfere with other packet processing operations being performed by the processor such as de-multiplexing, error correction, etc. This may be particularly problematic in the case of streaming, where the increased processing cost incurred may slow the processor down and unduly interfere with the real-time requirements of the streams. Secondly, if security is implemented in software then the security algorithms may be vulnerable to hacking, and so there is an increased risk of security being compromised.
It would be advantageous to allow security processing to be performed in software on a processor, but at the same time reduce the perturbance this has on other packet processing operations due to the increased processing cost incurred by the security processing. It would also be advantageous to reduce the security risk incurred by performing security processing in software.